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ABSTRACT 

We identify the obstacles hindering the deployment of In¬ 
formation Centric Networking (ICN) and the shift from the 
current IP architecture. In particular, we argue that scala¬ 
bility of name resolution and the lack of control of content 
access from content providers are two important barriers 
that keep ICN away from deployment. We design solutions 
to incentivise ICN deployment and present a new network 
architecture that incorporates an extra layer in the proto¬ 
col stack (the Location Independent Routing Layer, LIRA) 
to integrate location-independent content delivery. Accord¬ 
ing to our design, content names need not (and shonld not) 
be permanent, but rather should be ephemeral. Resolution 
of non-permanent names requires the involvement of con¬ 
tent providers, enabling desirable featnres snch as request 
logging and cache purging, while avoiding the need for the 
deployment of a new name resolution infrastructure. Our 
results show that with half of the network’s nodes operating 
under the LIRA framework, we can get the full gain of the 
ICN mode of operation. 

Categories and Subject Descriptors 

C.2.1 [Computer-Communication Networks]: Network 
Architecture and Design— Distributed networks 
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1. INTRODUCTION 

Network routing based on content identifiers has recently 
become a topic of extensive discussion, due to the benefits 
that could be provided by a location-independent data dis¬ 
tribution network [43], more commonly referred to as an 
Information-Centric Network (ICN). For instance, the ICN 
request-response mode of operation alleviates client mobility 
issues [41] and natively supports interdomain multicast [36]. 
Furthermore, content security (as opposed to channel secu¬ 
rity) is inherently supported by transmitting signed copies 
of content [17]. This in turn allows for in-network caching, 
which can transform the Internet into a native content dis¬ 
tribution network [44]. Finally, as shown recently [32], the 
ICN paradigm can bring benefits also at the transport layer, 
where caches can be exploited to alleviate congestion. 

On the other hand, enormous effort has been spent to 
de-ossify the end-to-end Internet transmission model to en¬ 
able new functionalities. Examples include IP Multicast and 
Anycast and supporting IP mobility at the network layer 


[15], [4], [18]. However, the difficulties of deploying those 
solutions at large scale led to the design of application- 
layer solutions such as overlay caching instead of native, 
in-network caching, overlay indirection techniques [39], [30], 
[20], DNSSEC and IPSEC to enhance security, just to name 
a few. Even though these solutions have the potential to en¬ 
able new services (or applications), they appear inferior com¬ 
pared to an ICN mode of operation, as they cannot natively 
support security, mobility, in-network caching and multicast: 
in all cases the in-network forwarding entities are forced 
to operate on the five-tuple <sourceIP, destinationIP, 
sourcePort, destinationPort, protocol> being, therefore, 
completely content-agnostic. 

Arguably, the ICN paradigm has the potential to deal with 
the Internet’s most daunting problems in a native manner. 
To reach this point, however, a new architecture based on 
core ICN principles will have to be deployed over the current 
IP Internet architecture, clearly, a rather challenging task. 

In this paper, we identify two main obstacles that hin¬ 
der the deployment of ICN on top of the current Internet. 
These are: i) scalability of name resolution, a core network¬ 
ing problem [28] and ii) content provider-controlled access to 
content, a business model problem, which however, is deeply 
integrated into the core networking principles of today’s In¬ 
ternet and therefore, affects the design of any new architec¬ 
ture. Content access control here is linked to content access 
logging and the transmission of content transparently to the 
content provider from in-network caches. We discuss each 
of these two challenges in more detail next. Based on these 
considerations, in this paper, we propose a fully backward- 
compatible and incrementally-deployable ICN-oriented ar¬ 
chitecture that meets scalability concerns, but at the same 
time takes into account the business requirements of the 
main Internet market players. 

1.1 Name resolution scalability 

Two main schools of thought have emerged in the ICN- 
related literature regarding name resolution and name-to- 
location mapping. The first one, mainly adopted by the 
original CCN/NDN proposal [17], advocates the hop-by-hop 
resolution of requests or Interests at the data plane. Ef¬ 
fectively, name resolution is coupled with name-based for¬ 
warding with each Interest packet being locally resolved to 
the next (router) hop. This approach has the advantage of 
locally making forwarding decisions, but on the downside, 
huge volumes of state need to be maintained in (manually- 
set) FIB tables [29]. CCN/NDN routers effectively have to 
keep state per packet, an issue traditionally considered as an 



implementation challenge [40].^ To deal with the scalabil¬ 
ity problems [22] of the original proposal and the huge state 
that needs to be kept at all routers, recent developments 
in the NDN space have proposed an NDN-based DNS sys¬ 
tem, dubbed NDNS [1], as well as the involvement of content 
providers to help in the name-resolution process [2]. 

The second school of thought decouples name-resolution 
from name-based routing by using a separate name-resolution 
system, similar in nature to DNS {e.g., [11], [5], [42], [21]). 
Although this approach avoids pushing excessive state to 
router forwarding tables, it requires the deployment of new 
infrastructure by operators. For instance, as shown in [22], 
the support of the DONA [23] architecture at tier-1 Au¬ 
tonomous Systems (ASes) requires the deployment of small- 
to-medium size data centres to support name resolution. 
Such, extra infrastructure built in from scratch has the ob¬ 
vious downsides of huge investment requirements, as well as 
the shift challenge to this new mode of operation. 

Moreover, focusing on the practical deployment of ICN, 
the full cycle of the name resolution process still remains 
unclear. Name resolution and data delivery mechanisms of¬ 
ten build on the implicit assumption that content names or 
identifiers are already available to the end users, prior the 
aforementioned coupled or decoupled resolution steps. Obvi¬ 
ously, developing a mechanism for the retrieval and delivery 
of content names to the end users raises concerns regarding 
both scalability aspects related to the enormous size of the 
namespace, and compatibility issues with respect to both 
application and network layer interfaces. 

We also note that the requirements of today’s dynamic 
and interactive applications would not be served adequately 
by fully transparent in-network caching driven solely from 
search engine content name results. We discuss and evaluate 
these concerns later. 

1.2 Content access control 

Content Providers (CPs) and CDNs require, for commer¬ 
cial and regulatory reasons, full control over the content re¬ 
quested and transferred. This has been largely overlooked by 
research efforts in the ICN area, which have mainly focused 
on naming schemes and name resolution systems to address 
scalability issues. For instance, the consensus around opaque 
and permanent content names ignores the fact that content 
can be served from ISP-operated in-network caches, trans¬ 
parently to the CP or CDN. “Pay per c/icfc”business models, 
however, would face significant limitations from this design 
choice in an ICN setting, that would practically prevent CPs 
and CDNs from billing their customers. Alternative ap¬ 
proaches based on ISP-CDN collaborations to log content 
requests cannot but be unrealistic: DNSs can keep track of 
requested content and could possibly report back to the rel¬ 
evant CPs/CDNs. This, however, would mean that SLAs 
should be in place between all ISPs and all CPs/CDNs at a 
global scale, a rather unrealistic assumption. 

At the same time, transparent in-network caching mech¬ 
anisms would typically allow only limited control over the 
content delivered to clients. That is, coarse grained TTL- 
based mechanisms would be the only means for CPs/CDNs 
to manipulate updated content, leading either to the deliv¬ 
ery of stale content, or the unnecessary delivery from the 


^See also [27] for an elaborate discussion on issues related to 
web transfers where the current NDN model is not sufficient. 


CP. That said, active cache purging is another requirement 
that calls for control of content from CPs and CDNs. 

Although content access control might sound as a trivial 
implementation or a business model issue, we argue that it 
might well hinder the engagement of CPs and CDNs from 
the adoption of ICN. Summarising, we argue that these con¬ 
cerns of: i) scalability and incremental deployment support 
of a name-oriented architecture, and ii) exclusive content 
access control at the CP side with simultaneous support for 
transparent in-network caching have been overlooked by the 
community so far. As a consequence, the full potential of an 
ICN mode of operation has not been exploited in full yet, 
making the adoption and deployment of the ICN paradigm 
an unrealistic target. 

1.3 Contributions 

Although clean slate research has revealed many of the 
benefits that ICN can bring, we argue that deployability 
has to be put at the forefront of any ICN design, rather 
than being treated as an afterthought. We address the de¬ 
ployability concerns discussed above by introducing a novel 
information-focused network architecture, which overcomes 
scalability concerns and is fully backward compatible with 
the current IP architecture. 

Our proposed architecture first introduces a name reso¬ 
lution process tailored to carefully manage information ex¬ 
posure e.g., enabling content access logging (Section 2.1). 
This name resolution process is combined with a new naming 
scheme, which builds on the notion of ephemeral names (Sec¬ 
tion 2.2). Name resolution is controlled by content providers 
based on a fully backward-compatible mechanism that sup¬ 
ports in-network caching and the direct control of ephemeral 
names’ lifetime, thus facilitating content access logging and 
active purging of stale cached data. The proposed mecha¬ 
nism completes the full cycle of the name resolution process, 
delivering content names to clients, without imposing any 
requirement for additional mechanisms. 

In-network caching, name-based routing and support for 
network-layer multicast are all integrated in the Location- 
Independent Routing Layer (LIRA), an extra layer in the 
protocol stack placed at “level 3.5” of the protocol stack, 
above the IP and below the transport-layer (Section 2.3). 
LIRA “absorbs” the location-independence nature of ICN, 
leaving the network layer to operate based on IP addresses. 
Resolution of content names does not rely on large vol¬ 
umes of FIB table entries, and routing takes place based 
on a hybrid of IP addresses (at the IP layer) and location- 
independent transient content names (at the LIRA layer) 
(Section 3). Our design does not require blanket adoption 
in order to realise the benefits of ICN. Instead, ISPs can in¬ 
crementally deploy LIRA nodes with little investment. Fur¬ 
thermore, the fact that routing is (in the worst case) based 
on IP addresses guarantees full backward compatibility with 
the current Internet architecture. Our results show that 
even with a subset of nodes upgraded to support LIRA func¬ 
tionality, our design achieves considerable performance gains 
(Section 4). 

2. CONCEPTS AND COMPONENTS 

2.1 Content provider-assisted name resolution 

In order to deal with the scalability concerns raised above, 
we design a name resolution scheme which involves the con- 



tent provider and does not require extra name-based reso¬ 
lution machinery [e.g., [5], [42], [11], [7]), or manually-set, 
bloated FIB tables {e.g., [17], [13]). In particular, any user 
will have to consult the CP (or CDN) and “ask” for the 
name/contentID before any content transfer can start (see 
next section for details on the contentlD). Users reach the 
content provider based on the standard procedure of the 
current Internet, that is, based on URLs, DNS resolution 
and IP addresses. This first part of the resolution (ie., 
reaching the CP to get the contentlD) is based on IP ad¬ 
dresses and is location-dependent. We note that users do 
not get the whole of the chunk from the CP (but only the 
contentlD), which can be served from any other cache in 
the network. In this way, we realise semi-transparent in- 
network content caching, which we argue is in the best in¬ 
terests of both CP/CDNs and ISPs alike. As discussed later 
on in this section, the second part of the name resolution, 
which also leads to the content transfer itself is location- 
independent, according to the philosophy of ICN. Summaris¬ 
ing, the “content provider-controlled name resolution proce¬ 
dure’’introduced here is fully backward compatible and does 
not require extra investment from ISPs, or CPs/CDNs. 

2.2 Ephemeral Names 

To provide full content access control to CPs, we intro¬ 
duce the concept of ephemeral names, which are used for 
location-independent content delivery. Our primary motiva¬ 
tion behind the introduction of ephemeral names is to avoid 
dissemination of the name/cID of a content to other users, 
as this could potentially lead to accessing the content from 
in-network caches, transparently to the CP/CDN. This sec¬ 
tion explains the structure, usage and design principles of 
these names. 

2.2.1 Name Structure 

The LIRA architecture uses flat names composed of two 
parts (see Fig. 1). The main part of the naming structure, 
the contentlD, or cID reflects the name of the content it¬ 
self and is based on the premise of ephemeral or transient 
names. According to this concept, content providers choose 
arbitrary strings and assign them to the content they host. 
The names are flat. In the sense that they bear no struc¬ 
ture related to routing {e.g., aggregation); however, CPs 
may impose structures related to the Internal organisation 
of their content. Ephemeral names should be unique to 
guarantee collision-free name resolution, which can be easily 
achieved with the use of arbitrary hashes. The names are 
self-certifying and “expire” after some time interval.^ This 
transitioning interval should be coarser than the time needed 
to support in-network caching and multicast {e.g., names 
should not change on a per-request basis) - see Section 2.2.3 
for details. 

The second part of the ephemeral name, the serviceOp- 
tions, can be used to realise preferential treatment of con¬ 
tent. Although the use of this part of the name is not neces¬ 
sary in our architecture, and is not necessarily of ephemeral 
nature, we believe that it can help in the caching and schedul¬ 
ing process. For instance, the serviceOptions part can be 
used to flag content that should or should not be cached. 
We leave such investigations for future work. 

^A few randomly set padding bits can be used in each named 
chunk to preserve both the self-certifying and the ephemeral 
character of names, without inflating the chunk size. 


E.g., Cache privilege cID obtained by CP 
/service_Options /contentlD 

^-V-^ 

servicelD (sID) cID is ephemeral 

Name change granularity coarser than 
characteristic time of cache 

Figure 1: Ephemeral Names 

2.2.2 Incentives and Disincentives for Adoption 

In case of permanent names, search engines would operate 
based on names (similarly to today’s operation based on 
URLs). This operation is clearly not in the best interests 
of CPs/CDNs given the “pay per c/icfc” models in use today 
and transparent in-network caches used in ICN. 

Transient names dis-incentivise search engines from dis¬ 
seminating cIDs, but at the same time allow for both access 
logging at the CP/CDN and transparent in-network caching. 
One might claim that search engines would prefer to provide 
the cID directly to users, as this would lead to faster content 
access {i.e., users would not need the extra RTT to travel to 
the CP/CDN to get the cID). However, given (i) the tran¬ 
sient character of names, and (ii) the delivery of bundles of 
cIDs by CPs (see Section 2.2.3), this would require search 
engines to devise mechanisms for retrieving and disseminat¬ 
ing cIDs each time they change, only to save a single RTT 
in each bundle. This limits the incentives of search engines 
to provide cIDs without the consent of CPs/CDNs. 

Moreover, and most importantly, ephemeral names allow 
CPs/CDNs to actively control the cached content served to 
their clients e.g., by changing the cIDs of content chunks 
existing cached copies get practically invalidated. This is an 
important feature of the proposed approach, which cannot 
be supported in alternative proposals {e.g., [17, 9, 13]). 

2.2.3 Transitioning Interval 

The combination of the name resolution at the CP, to¬ 
gether with the ephemeral nature of content names supports 
a number of desirable features. First and foremost, name 
resolution is under the control of the CP, enabling access 
logging. Secondly, versioning of updated content and purg¬ 
ing of old content from in-network caches is also under the 
control of the CP. Although TTL-like techniques, such as 
the CCN staleness option, can support content updating, it 
is not easy to set such values given today’s interactive ap¬ 
plications. Setting TTL values for individual content items 
{e.g., [3]) would always face the tradeoff of short TTLs re¬ 
sulting in unnecessary delivery from the content provider, 
while longer TTLs would result in delivering outdated con¬ 
tent. Using ephemeral names, cached content can instead 
be actively invalidated when needed. 

Along the same lines, the transitioning interval of ephemeral 
content names Is an issue that requires further attention 
and is related, among others, to the popularity of the con¬ 
tent as well as the size of content chunks. Frequent change 
of the name can result In suboptimal performance, since 
each change purges the content in caches. We deal with 
this tradeoff by setting the transitioning interval of content 
names to a value inversely proportional to the popularity of 
the content itself. Popularity is measured by the CP and 
can be based on the number of requests for the content in 
question, per some time interval. Although more sophisti¬ 
cated settings can be found, with this simple setting for the 



transitioning interval we avoid changing the cID of rarely 
accessed content too frequently, and we also avoid leaving 
the cID of popular content the same for too long. Finally, 
to alleviate the need to travel to the CP for every chunk re¬ 
quest, we assume that upon each request for a content item, 
the CP sends back to the client the “up-to-date” ephemeral 
names of the next few subsequent chunks, that is, not only 
the name of the immediately following one. The number of 
subsequent cIDs sent by the CP to the client is left for future 
investigation. 

2.3 LIRA: Location-Independent Routing Layer 

Adding extra functionality, or altering completely the op¬ 
eration of existing core network protocols can prove difficult 
to be done incrementally {e.g., IPv6) and “flag-days” are 
not an option for incorporating new components at a global 
scale. For these reasons, we propose addition instead of 
replacement of an extra layer to the protocol stack, which 
we call Location-Independent Routing Layer (LIRA). LIRA 
sits on top of the network (IP) layer and below the trans¬ 
port layer. It operates based on ephemeral names and in¬ 
tegrates all the required functionality to realise location in¬ 
dependence, taking advantage of information centricity and 
its well-known gains [43]. 

Although recent studies have proposed HTTP as the layer 
that can integrate information or content centricity [30], here 
we argue that in order for in-network caching and multi¬ 
cast to be smoothly incorporated in the new ecosystem, any 
information-centric operation needs to be below the transport 
layer. Otherwise, the transport protocol can merely con¬ 
nect two specific endpoints cancelling any notion of location- 
independent content transfer. Instead, breaking the end-to- 
end transmission model below the transport layer allows to 
leverage (ICN enabled) in-network caching, both in terms of 
native multi-source routing and localised congestion control 
[32], going far beyond traditional IP Multicast or Anycast 
mechanisms. 

LIRA is implemented in just a small subset of nodes (see 
Section 2.5), which can be transparently planted in the net¬ 
work, and it manages incoming and outgoing content based 
on their names. The main name management functionality 
is implemented in a routing table, which we call Content 
Forwarding Information Base (C-FIB) (Section 2.4). 

A similar notion to the LIRA layer has been proposed in 
the past in [8], but in a totally different context, addressing 
the exhaustion of IPv4 addresses. The evolution of NAT 
boxes (together with the painfully slow incremental deploy¬ 
ment of IPv6) has dealt with this problem and hence, the 
related efforts became obsolete. 

2.4 Content Forwarding Information Base 

The Content Forwarding Information Base (C-FIB) ta¬ 
ble keeps track of recently requested and served content (in 
terms of cIDs) and maintains forwarding information used 
for the delivery of those content items, providing also sup¬ 
port for in-network caching and multicast. Upon subsequent 
request(s) for a content already in the C-FIB table, LIRA 
is redirecting requests towards the direction where the con¬ 
tent has been sent, or served from, similarly in principle to 
breadcrumbs routing [33]. 

We note that the C-FIB table essentially acts as a cache 
for cIDs served recently through this router (somewhat sim¬ 
ilarly to [26] and [14]). However, C-FIB table entries are 


not permanent, as in CCN’s FIB, but rather are assisting 
in location-independent content delivery from neighbouring 
nodes (see Section 3 for details on the C-FIB structure). 

The typical structure of the C-FIB table is illustrated in 
Table 1. The table maintains one entry per content chunk. 
The following information is maintained for each entry: i) 
cID, the content identifier of the chunk, ii) ifi, the incom¬ 
ing interface i.e., the index of the interface from which the 
content is received, that is, the content source indicated by 
the DNS, Hi) ifo, the outgoing interface i.e., the index(es) 
of the interface(s) towards which the content is currently 
being forwarded, iv) ifri, the temporary interface, i.e., the 
index(es) of the interface(s) where the content has been for¬ 
warded, v) mIP, the multicast IP field that holds IP ad¬ 
dresses of clients participating in a multicast session. Note 
that interface entries in the C-FIB table denote real inter¬ 
faces {i.e., directions towards which requests/content should 
be forwarded) and not IP addresses of sources/destinations 
(apart from the multicast IP field). By doing so we realise 
the location independence property of ICN in LIRA. 

2.5 LIRA Nodes 

The LIRA node structure is the main component of the 
proposed architecture, which integrates information centric¬ 
ity. LIRA nodes implement the LIRA layer with its C-FIB 
table discussed above in order to realise named content man¬ 
agement and subsequently location independence. LIRA 
nodes also include caches that temporarily store named con¬ 
tent chunks {i.e., in-network caching). Although by default 
all LIRA nodes include both the C-FIB table and content 
caches, we also evaluate (in Section 4) the case of “lighter” 
LIRA nodes, where, based on node centrality metrics and 
to facilitate incremental deployment, some nodes implement 
the C-FIB table and some others implement caches. 

Our design does not require all nodes of a domain to be¬ 
come LIRA nodes and it is operational regardless of this. 
Being always based on IP, nodes fall back to normal IP oper¬ 
ation and route towards the direction indicated by location- 
based addresses. Note that all routers maintain the default 
IP-based FIB table. Therefore, incompatibility issues or re¬ 
quirements for simultaneous shift to ICN operation do not 
exist. As we show later on in the evaluation section, an 
average of 50% of nodes within a domain can provide con¬ 
siderable performance gain. Careful network planning {e.g., 
depending on topological issues) and incremental upgrade 
of normal routers to LIRA nodes gives a major advantage 
to the proposed architecture in terms of deployability com¬ 
pared to other ICN architectures. 

3. OVERVIEW OF MAIN OPERATIONS 

We proceed with the description of the name resolution 
and content delivery process, illustrated in Fig. 2. We then 
give details of the entries of the Content Forwarding In¬ 
formation Base (C-FIB) table during the content delivery 
process. For this purpose we use the network topology pre¬ 
sented in Fig. 3. Tables 1 and 2 are also used to present the 
entries of the C-FIB table(s) for a sequence of important 
events taking place in our example scenarios (denoted with 
timestamp L). 

3.1 Name Resolution and Content Delivery 

The name resolution process is initiated through existing 
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Figure 2: Name resolution and content delivery 
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protocols (i.e., DNS and HTTP) to guarantee backwards 
compatibility and facilitate adoption of ICN. 

As a first step (Fig. 2) and identically to what is hap¬ 
pening today, users resolve URLs through a request to the 
DNS. The DNS responds with the IP address of the 

content provider. The user generates an HTTP HEAD 
request [16] at the application layer. At this stage, routing is 
location-dependent and is based on the IP address indicated 
by the DNS. At the content layer, the request is asking for 
the cID. The CP sends back an HTTP response packet 
containing the up-to-date name, i.e., cID, of the requested 
content in the ETag field of the HTTP response header [16] 
The destination IP address of that packet is that of the re¬ 
questing client. This packet can be piggybacked with data 
to avoid an extra RTT between the client and the CP. In 
this case, however, given that requests are sent per chunk, 
we cannot take advantage of in-network caching. This op¬ 
tion can be considered in special cases {e.g., when a client 
is close to the CP and chances of finding the content cached 
are slim). The client issues a request for the first chunk 
of the content object [e.g., client A in the example of Fig. 3). 
The request includes the IP address of the CP at the IP layer 
and the cID of the chunk at the LIRA layer. 

LIRA nodes along the path check the cID included in 
the request^ against the entries of their C-FIB table. If an 

®It is noted that the use of the ETag field for name resolution 
does not change the semantics of the field as it is intended to 
describe the content to be delivered and/or cached. More¬ 
over, no restrictions apply to the format of this field allowing 
the realisation of ephemeral names. 

^We rely on the Protocol field of the IPv4 header (or the 
“Next header” in the IPv6 header) to enable LIRA nodes to 
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entry for the cID exists, then they forward according to this 
entry. If not, they forward according to the IP address. The 
IP address points to the CP, hence, content can always be 
resolved according to that in the worst case, e.g., in case of 
LIRA-incompatible nodes or domains. 

At this point, assuming the content is not locally cached 
(see Section 3.2 for details on in-network caching), the re¬ 
quest is forwarded towards the CP. The index of the network 
interface used to forward the request is marked as the ifi 
for this content chunk (i.e., interface 1 - see time ti in Ta¬ 
ble 1). At the same time, the index of network interface 
from which the request was received is marked as an output 
interface (interface 3 in our example). The content chunk 
is then sent back from the CP (or any other cache further 
down the path). During the data transfer no change is made 
in the C-FIB table entries of intermediate LIRA nodes (time 
ti). When the chunk transfer completes, which is denoted by 
an End of Chunk (EoC) field, the intermediate LIRA nodes 
change their C-FIB entries for this cID by marking the in¬ 
terfaces through which they forwarded the data (i.e., ifo) 
as ifn (temporary interface) - interface 3 is moved to ifri 
at t 2 in Table 1. This is done since the content can possibly 
be delivered from there too (i.e., the content has possibly 
been cached towards this direction). When the client sees 
the EoC field/bit set, it forwards the next request towards 
the original CP (similarly to the initial request - step (^^ 
above) in order to obtain the cID of the next chunk. 

3.2 In-Network Caching 

LIRA nodes by default support in-network caching. In the 
simplest case, on-path in-network caching is supported by 
simply performing a lookup of the cID of a request message, 
at the local cache index. In case the requested content chunk 
is cached locally, the corresponding data is returned through 
the network interface the request was received from (ifo). 
In our example scenario, client B issues a request for content 
xi. Once the request for xi reaches Ra, the C-FIB table of 
Rs is updated to include ifi = 1 and ifo = 2 (ts in Table 
2). Then, at time t^, the request for xi reaches Ri. Content 

identify those IP packets that can be handled by the LIRA 
layer i.e., containing an ICN content name. 


















































chunk a:i is found cached at Ri whose interface 2 is marked 
as ifo and the content is sent towards client B. 

By introducing the ifri field in the C-FIB table we fur¬ 
ther realise off-path in-network caching [26], as well as user- 
assisted in-network caching [25], [37]. When a content chuck 
is not found in the local cache, the LIRA node sends the 
received request towards both the (permanent) incoming in¬ 
terface if I (as indicated by the name resolution process) 
and the temporary interface(s) ifn- In our example, Ri 
sends two requests for xi towards both the (permanent) ifi 
1 and the ifri 3 (t 4 in Table 1). Whichever of the two in¬ 
terfaces (1 or 3) starts receiving the requested data first is 
marked as the incoming interface for this content and the 
remaining (temporary) interfaces are pruned down. Prun¬ 
ing here can be realised through a negative ACK (NACK) 
packet which travels towards the source of the content. If 
if I answers hrst, the ifn is removed from the correspond¬ 
ing C-FIB table entry. Alternative strategies can be applied 
here, by selectively forwarding a request to one or more of 
the available interfaces e.g., always forwarding only towards 
an off-path cache, since requests are always routable to the 
CP at the IP layer. 

Finally, at time ts when xi transfer completes (from either 
the local, or a remote cache), interface 2 is added to the list 
of temporary incoming interfaces (ifn) at i?i, since xi can 
now be found this way too (similarly to t 2 ). The C-FIB 
table of 7?3 is also updated to include interface 2 as ifn 
(step te). 

We note that in order to avoid routing loops in case no 
other device towards ifxi (client A in our case) has the con¬ 
tent cached, we discard requests (for items in the C-FIB 
table) that come in through its marked ifn- This is done 
because any LIRA node towards the ifxi (client A in this 
case) will forward the request based on its IP address (car¬ 
ried at the IP layer and always pointing towards the per¬ 
manent content source, hence through Rl in our example) 
if it finds no entry in its C-FIB table for the requested con¬ 
tent. In turn, upon receipt of the request, Rl will send the 
request back towards the same direction (towards client A 
here), since it still has got the related entry in its C-FIB ta¬ 
ble. This will result in the request travelling back and forth 
creating an endless routing loop. 

3.3 Multicast 

Multicast support is enabled through the use of the ifo 
and mIP fields of the C-FIB table. As described above, dur¬ 
ing the chunk transfer, the network interface of the LIRA 
node where the incoming data is forwarded towards is marked 
in the ifo field. This ifo entry enables the LIRA node to 
suppress any subsequent request for the same content chunk 
by adding an extra outgoing interface to its C-FIB. This is 
similar to the PIT functionality in CCN [17].® Note that 
in all above steps the IP address (at the IP layer) of re¬ 
quest packets has been pointing to the CP and of content 
chunks to the corresponding clients. However, in order to 
realise multicast transmission in this case {i.e., avoid send¬ 
ing a second request for the same chunk towards the same 
direction), the LIRA node that suppresses subsequent re¬ 
quests needs to keep the extra IP address of the clients that 
generated the requests. We deal with this situation through 
the “multicast IP” (m/P) field in the C-FIB table. When 

® Effectively, the C-FIB collapses both the CCN FIB and 
PIT in one table. 


data arrives at the branching LIRA node, it gets forwarded 
to all ifo interfaces. The mIP entries are used at the IP 
layer to allow for the delivery of the duplicated data to the 
requesting recipients. 

Note however that multicast forks further down the path 
are handled locally. In our example, if an additional client 
C attaches to P 3 and requests for X 2 during the multicast 
session, its request will be suppressed by P 3 which will also 
store client C’s IP address in the corresponding mIP held. 
Rl will not be aware of client C’s existence and P 3 is respon¬ 
sible for duplicating data for this client. Thus, the mIP 
state load is distributed to the participating LIRA nodes 
avoiding the overloading of nodes closer to the root of the 
multicast tree. 

In our example network, client A issues a request for con¬ 
tent X 2 - The C-FIB table at Pi marks ifi — 1 and ifo = 3 
for cID X 2 (step tr). Before the transfer of X 2 towards A 
completes through Pi client B issues a request for X 2 , which 
goes through P 3 and reaches Pi. P 3 updates its C-FIB ta¬ 
ble by putting ifi = 1 and ifo = 2 (step ts). Pi does not 
forward this request further; instead it adds interface 2 to 
the ifo held of X 2 and also stores the IP address of client 
B (taken from the corresponding IP layer held) in the mIP 
held (step tg). 

When X 2 arrives at Pi (step tg) it is forwarded towards 
client A through ifo = 3, but it is also replicated and for¬ 
warded towards client B, through ifo = 2, using mIP as the 
destination IP address. When the chunk X 2 transfer com¬ 
pletes, router Pi moves interfaces 2 and 3 and P 3 moves 
interface 2 to the ifn held (step fio - Table 1 and 2). 

Note that the C-FIB table introduced here, incorporates the 
functionality of both the PIT and the FIB tables of CCN. 
For as long as the chunk transfer goes on and hence, the 
ifo held is hlled (and the ifn held is empty - ti,tr and tg 
in Pi’s C-FIB, see Table 1), the C-FIB table represents the 
PIT table of CCN/NDN. That is, based on this state, LIRA 
nodes are able to collapse/suppress subsequent requests for 
content already requested (or under transmission) and re¬ 
alise multicast. When the chunk transfer completes and the 
entry in ifo is moved to the ifn held and tig 

in Table 1), then the C-FIB table rehects the FIB table of 
CCN/NDN. As mentioned above, however, the C-FIB table 
acts as a cache for recently served content and hence, it does 
not need to keep huge amounts of state information in the 
FIB part of the C-FIB. We discuss and evaluate both parts 
of the C-FIB table later in Section 4. 

4. PERFORMANCE EVALUATION 

It is generally not common to evaluate a network architec¬ 
ture merely in quantitative terms, given that the contribu¬ 
tion of such studies comes mainly at a conceptual level. In 
our case, the contribution of the LIRA architecture comes 
mainly in terms of incremental deployment with backward 
compatibility guarantees. At the same time, however, LIRA 
can achieve all the quantihable benehts of an ICN mode of 
operation. 

To provide a thorough performance evaluation, we analyse 
conceptual and qualitative gains in Sec. 4.1 as well as quanti¬ 
tative gains in Sec. 4.2. The quantitative evaluation focuses 
on the deployment of the LIRA concept from the operators 
perspective. In particular, given a fixed monetary budget 
that the operator is prepared to spend in order to deploy 



LIRA, we assess the best strategies of investing the capital 
in terms of extra equipment, which in our case translates 
to cache memory and C-FIB tables. We also demonstrate 
and quantify the benefits brought by LIRA to CPs, with a 
particular focus on cache purging and the control over the 
freshness of the cached content. 

4.1 Qualitative Evaluation 

Name resolution: by handing control of the name res¬ 
olution process to CPs, LIRA avoids the need for either the 
deployment of a costly name resolution infrastructure, or 
the investment on in-network resources for the support of 
line-speed name resolution. The operation of the C-FIB as 
a cache for names/cIDs is similar to [14]. However, LIRA 
does not necessitate the use of an explicit off-path name res¬ 
olution mechanism, as it rather falls back to IP, in a back¬ 
ward compatible manner. At the same time, by following 
a backwards compatible HTTP-supported name resolution 
mechanism, LIRA presents a complete interface for the in¬ 
teraction of end-hosts with an information-centric network. 
To the best of our knowledge, no exact mechanism has been 
proposed for the discovery {i.e., not only resolution) of con¬ 
tent names in alternative ICN architectural proposals. 

Control of content access: LIRA enables CPs to di¬ 
rectly monitor and control the access of end users to their 
content. Route-by-name approaches such as [17] fail to pro¬ 
vide such support. CPs would be reluctant to accept trans¬ 
parent access to their content, thus dis-incentivising the 
adoption of such an approach to ICN by ISPs. Lookup- 
by-name approaches, on the other hand, such as [10] and 
[21], enable this type of control, by decoupling name reso¬ 
lution from forwarding. However, this comes at the cost of 
additional name resolution infrastructure and directly places 
the content access information in the hands of ISPs; in turn, 
this introduces the burden of new (business and technical) 
interfaces between all CPs and all ISPs at a global scale. 

Mobility: although the issue of mobility in case of LIRA 
requires further investigation and at first sight it might seem 
that LIRA cannot deal with mobility efficiently, due to its 
dependence on IP, we note the following: upon a content 
request, the CP or CDN is sending back to the client the cIDs 
of the next few chunks, i.e., not just the next one. That said, 
the clients operate based on IP-agnostic cIDs. Therefore, 
client mobility can be natively supported, as clients request 
for content based on identifiers (in combination to the IP 
address at the IP layer). Source mobility, on the other hand, 
is an issue that requires further investigation as is the case 
with all ICN architectural proposals. 

Security: by supporting self-certifying cIDs, LIRA se¬ 
cures the content itself rather than the communication chan¬ 
nel, similarly to other ICN architectures e.g., [17]. 

Implementation: the proposed LIRA functionalities can 
be deployed on nodes with only firmware updates without 
the need for hardware replacement or upgrade. In fact, 
by relying on IP forwarding as a fallback in case of C-FIB 
misses, LIRA will never result in un-routable requests/content 
even if deployed on just a few nodes and with minimal mem¬ 
ory. This is in stark contrast with previous ICN proposals 
like CCN and NDN which require well-dimensioned FIB and 
PIT structures to operate correctly and at line speed. C-FIB 
can be loaded in DRAM, which has been shown to be able 
to support line-speed per-packet lookups [45], [28], is inex¬ 
pensive and abundant on modern routers based on either 


network processors or general purpose processors. It is in 
fact common to have at least a few GBs of spare DRAM 
on modern routers. Since the binary code implementing 
LIRA functionalities is likely to require negligible space, all 
available DRAM can be used for C-FIB and caching space. 
C-FIB entries in particular have very low memory require¬ 
ments. In fact, even assuming that (i) the C-FIB is imple¬ 
mented using a hash-table with a load factor of 0.5 and with 
a circular queue for replacement and (ii) the unfavourable 
case that LIRA chunks are named using SHA-512 hashes 
and next hops information are coded on 2B, it is still possi¬ 
ble to store over 15 million C-FIB entries per GB of DRAM. 
This makes G-FIBs and more generally the LIRA node ar¬ 
chitecture easy to incrementally deploy on today’s routers. 

4.2 Quantitative Evaluation 

As mentioned earlier, the objective of this section is to 
evaluate the best possible way to invest in deploying the 
LIRA concept, from the operator’s perspective. That said, 
we initially evaluate the main concepts of our proposal with 
regard to their projected gains in terms of cache hits. Al¬ 
though LIRA is far from a caching-specific architecture, caching 
is: i) the only straightforward quantitatively measurable as¬ 
pect of an IGN architecture, and most importantly, ii) the 
main feature that requires investment from network opera¬ 
tors. For these reasons and without by any means under¬ 
estimating the gains from the above-mentioned qualitative 
benefits of the LIRA architecture, in this section, we focus 
on the evaluation of the main concepts included in LIRA as 
seen from an in-network caching perspective. 

We use Icarus [35] to evaluate the performance of vari¬ 
ous aspects of our proposed framework based on real ISP 
topologies from the RocketFuel dataset [38] and synthetic 
workloads [19]. Due to space limitations, we omit evaluation 
of the multicast functionality offered by LIRA, since the re¬ 
lated performance benefit is straightforward. Moreover, we 
only show results for the Telstra and Abovenet topologies, 
though we report that we obtain similar results with other 
topologies as well. We make the code, documentation and 
data required to reproduce our results publicly available.® 

4.2.1 Efficiency of C-FIB and Deployment Strategies 

LIRA nodes can have a content cache or a C-FIB table, 
or both. Given a hxed total cache and C-FIB capacity bud¬ 
get, in this section, we identify the best possible combina¬ 
tion of cache and C-FIB deployment along two dimensions: 
i) deployment strategies and ii) caching strategies. We at¬ 
tempt to capture the interaction dynamics between nodes 
that cache content and nodes that can route to this content, 
in a location-independent manner, i.e., through C-FIB ta¬ 
ble entries. Our first objective is to investigate the effective¬ 
ness of C-FIB table entries in mapping the content cached in 
neighbour nodes. Our second objective is to see how C-FIB 
table entries eventually translate to cache hits. 

Modelling the performance of a network of caches is known 
to be complex [34], [12]. As a result, it is extremely difficult 
to formulate optimal cache placement algorithms which are 
also robust to realistic traffic variations. Arguably, the com¬ 
plexity of the optimal cache placement problem is another 
obstacle hindering ICN deployments. Therefore, motivated 
by practical reasons, we propose four simple content cache 
and C-FIB placement algorithms and show that they are 

®http://www.ee.ucl.ac.uk/~lsaino/software/lira 




Figure 4: C-FIB Freshness vs. Deployment Strate¬ 
gies and Caching Strategies, Zipf a = 0.8 



Fignre 5: Cache Hit Ratio vs. Deployment Strate¬ 
gies and Caching Strategies, Zipf a = 0.8 


sufficient to provide tangible performance gains even with 
partial deployments. To deploy caches and C-FIBs, we rank 
nodes according to their betweenness centrality (i. e., the 
amount of traffic traversing them following shortest path 
routing [6]) and deploy LIRA functionality using the follow¬ 
ing strategies: 

(i) Cache in top 50% high centrality nodes, C-FIB table in 
all nodes: {Ch,Fa). 

(ii) Cache in top 50% high centrality nodes, C-FIB table in 
top 50% high centrality nodes: {Ch,Fh). 

(ill) Cache in all nodes, C-FIB table in all nodes: (Ca, Fa)- 
(iv) Cache in all nodes, C-FIB table in top 50% high cen¬ 
trality nodes: {Ca,Fh)- 

We run simulations and measure the mean C-FIB fresh¬ 
ness, which we define as the ratio of entries stored in C- 
FIB tables which can correctly route to a copy of a content 
stored in a nearby cache. This metric captures how well the 
entries of the C-FIB tables deployed in the network reflect 
the current state of nearby caches. We further characterise 
the correct C-FIB entries by the hop distance to the LIRA 
node that caches the corresponding content. Note that in all 
cases, and regardless of the deployment strategy, the ratio 
of C-FIB table to cache entries is fixed (see next subsection 
for the evaluation of this ratio). As a result, C-FIB tables 
in fewer nodes (than those that deploy caches) keep more 
entries to match the number of cache slots (and vice versa). 

We also analyse the results under different caching strate¬ 
gies: Leave Copy Everywhere (LCE), according to which a 
copy of a content is stored in every cache traversed and ran¬ 
dom choice, according to which a content is stored only in 
one randomly selected caching node along the delivery path. 
The rationale behind our choice is to evaluate deployment 
and caching performance under varying caching redundancy 
[31]. Our results are shown in Figs. 4 and 5. 

C-FIB Efficiency. First of all, it is important to highlight 


the fact that the C-FIB table entries depict precisely the 
state of neighbour caches. This is proved by the fact that 
the freshness ratio in Fig. 4 directly translates to off-path 
cache gain in Fig. 5: for instance, the freshness result in case 
of {Ch,Fa) in Fig. 4a indicates that 5% of entries in the C- 
FIB table can correctly route to the content in neighbour 
caches. In turn, in Fig. 5a, the gain from off-path caching 
(red, top part of bar) is 4.5%. This is an important result 
that highlights the effectiveness of the C-FIB table in keep¬ 
ing an accurate record of the state of nearby caches {i.e., up 
to 3 hops away in our evaluation). 

Deployment Strategy. In terms of C-FIB freshness, de¬ 
ploying smaller caches over more/all nodes, i.e., {Ca,F„), 
seems to be more effective in capturing the state of caches 
from the C-FIB tables {i.e., higher freshness in Fig. 4). This 
is explained by the fact that the “monitoring and mapping” 
mechanism provided by the C-FIB table has got a wider view 
of the neighbourhood and can therefore, find more content 
items locally. This also translates to more off-path cache 
hits in Fig. 5 for (Ca,F*). 

Out of the four deployment strategies under considera¬ 
tion here, {Ch, Fh) and {Ch, Fa) consistently perform best 
in terms of cache hits (in Fig. 5). This is irrespective of the 
freshness result, which shows that freshness improves when 
caches are deployed over all nodes {i.e., {Ca,F„)). In other 
words, it is better to have fewer but bigger caches placed 
in high centrality nodes (as also shown in [6]), rather than 
having smaller caches deployed in all nodes of the network. 

Caching Strategy. As expected, in terms of cache hits, 
choice always performs best, for all topologies and for all 
deployment strategies, as a result of its reduced caching re¬ 
dundancy. Similar results have been reported before in [31]. 
LCF on the other hand, performs roughly the same across 
all deployment strategies. Note that the LCE result in Fig. 5 
effectively reveals the performance of the CCN/NDN archi¬ 
tecture. Due to space limitations, we do not present a full- 
fledged comparison between the architectures, but Fig. 5 re¬ 
veals very well the cache-related performance of CCN/NDN. 

4.2.2 Memory Requirements and Scalability 

We next quantify the performance benefit of off-path, C- 
FIB-routed, caching for various values of the C-FIB-to-cache 
size ratio (expressed in number of entries) and for the {Ch,Fa) 
strategy (Fig. 6). 

Considering the overall cache hit ratio (both on- and off- 
path), we see a considerable increase when moving from a 
ratio value of 0.25 to a ratio value of 16, due to C-FIB routing 
redirections. The results are similar for a ratio equal to 32, 
but the gain in this case is marginal. Therefore, given that 
larger memory is required in order to deploy C-FIB tables 
32 times bigger than the entries in the respective caches, we 
conclude that a value of 16 is optimal. Although in absolute 
values, off-path, C-FIB-based, caching contributes less than 
on-path caching, the gain is still far from negligible {i.e., 
it can reach up to 50% in Fig. 6). We report that in our 
simulations, the gain from off-path caching can reach 100%, 
effectively doubling the gain from on-path caching. 

Finally, it is interesting to note the slight decrease of on- 
path cache hit ratio as the C-FIB-to-cache size ratio in¬ 
creases. This is attributed to cases where a content request 
encounters a C-FIB table entry and gets diverted to an off- 
path cache, before it actually hits an existing on-path cache. 

























In this case, and given that the C-FIB table entry is found 
earlier in the path, we report that the delay to deliver the 
content back to the user is even shorter than finding the re¬ 
quested item in an on-path cache. This is especially so in 
case of LCE caching, where due to increased caching redun¬ 
dancy, a copy of a content has good chances of being found 
along the shortest path. 



(a) LCE 



(b) Random Choice 


Figure 6: Cache hit ratio vs C-FIB size, Abovenet 


4.2.3 Control of content to CPs 

One of the departing points in the design of the LIRA ar¬ 
chitecture is the direct control of content by the CPs/CDNs, 
as discussed earlier. We identify two main features that give 
direct control of the content to the CP or CDN. The first 
one is the control of access logging. In LIRA this is accom¬ 
plished by the content provider-controlled name resolution, 
where clients need to get the up-to-date cID from the con¬ 
tent provider. This requires an extra RTT to get to the CP 
or CDN. We remind that according to our discussion in Sec¬ 
tion 2.2.3, CPs/CDNs send more than one cID to the client, 
therefore, the journey to the CP/CDN happens rarely dur¬ 
ing the data transfer, or even only once in case of small files 
{e.g., web). We assume this extra RTT to incur only a tiny 
performance penalty compared to alternative proposals that 
do not necessarily require this extra roundtrip. 

The second feature that provides control of published con¬ 
tent to CPs is the ability to actively perform cache purging. 
As described in Section 2.2, when CPs change the cID of 
a content item, previously cached items no longer get hits 
from new requests and eventually get evicted (denoted as 
LIRA w/o replacement). Taking a step further, we consider 
an extended version of this mechanism, where data packets 
explicitly indicate the cID values of the content items that 
should be immediately evicted from encountered caches (de¬ 
noted as LIRA w/ replacement). 

Figure 7 shows the cache hit ratio of the above mecha¬ 
nisms along with that of a simple TTL-based mechanism, 
where any cache hit returns the content to the client, even if 
this content is stale {TTL-based (all hits)) for various TTL 
values. In Fig. 7, we see that the cache hit ratio in the 
( TTL-based (all hits)) case increases with the value of TTL, 
since content remains longer in the cache. However, this 
also means that the corresponding cache hits result in the 
reception of stale content. Fig. 7 also shows the cache hit 
ratio for fresh only content {TTL-based (fresh only)), which 
initially increases, but then steadily drops as a result of high 
TTL values that increase stale cached content. 

The LIRA w/ replacement mechanism performs consider¬ 
ably better than LIRA w/o replacement, as it immediately 
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Figure 7: Delivery of Stale Content 


frees the caching space from unnecessary stale content, and 
better than its TTL-based (fresh only) counterpart. 

It must be noted that the TTL-based (fresh only) ratio is 
only provided as a benchmark, as TTL-based mechanisms 
cannot avoid serving stale content. On the other hand, LIRA 
provides a precise mechanism to avoid serving stale cached 
content altogether. 

4.2.4 Incremental Deployment 

We proceed to evaluate the last of the design targets be¬ 
hind LIRA, that of incremental deployability. To assess the 
performance gain of incrementally deploying the LIRA ar¬ 
chitecture, we begin by progressively adding C-FIB tables 
starting from the highest centrality nodes. We evaluate the 
performance in terms of cache hits in case of caches deployed 
in 25%, 50%, 75% and 100% of the nodes, starting from the 
highest centrality ones. 

We observe in Fig. 8 that performance stabilises with the 
C-FIB table present in 20-30% of the nodes. C-FIB in less 
than 20% results in suboptimal performance, but perfor¬ 
mance does not increase considerably if we continue adding 
C-FIB to more nodes. In terms of caches, a 25% deployment 
rate results in poor performance, while the performance does 
not improve considerably when caches are deployed in more 
than 50% of nodes. The difference in performance between 
the 50% and 100% of nodes is in the area of 1% improvement 
in terms of cache hit ratio for the two topologies shown here 
(Telstra and Abovenet). 

We conclude that adding C-FIB to the top 20-30% highest 
centrality nodes and caches to 50%-75% of highest centrality 
nodes achieves the full performance gain of the LIRA archi¬ 
tecture. Although here we present results for Telstra and 
Abovenet topologies, our results are consistent along all six 
evaluated topologies of the RocketFuel dataset. 



(a) Telstra (108 nodes) (b) Abovenet (141 nodes) 

Figure 8: Incemental Deployment 
































5. CONCLUSIONS 

There is a constant trend towards extra “flexibility” in 
communication networks, which started with the shift from 
(rigid) circuit-switching to (queuing-based) packet-switching 
[24]. We see location-independent, information-centric net¬ 
working as the natural next step towards “content switch¬ 
ing”. To move towards this direction, however, the research 
community needs to take into account the interests of the 
main Internet market players, as well as those of users. 

We argue that ICN research so far has focused on de¬ 
signing conceptually sound and scalable name-based routing 
architectures, but largely ignored any incentives (provided 
through those architectures) to adopt the ICN technology. 
The interests of content providers and CDNs are largely dif¬ 
ferent to those of ISPs and the shift to an ICN environment 
environment makes this difference even more pronounced. 
That said, unless a shift to an ICN environment takes into 
account the interests of both CPs/CDNs and ISPs, the in¬ 
centives to adopt this technology will be limited. 

In this paper we have taken these concerns into consider¬ 
ation and have designed an incrementally-deployable ICN 
architecture. The proposed architecture is based on the 
Location-Independent Routing Layer (LIRA) and directly 
involves the content provider in the name resolution pro¬ 
cess. Furthermore, ephemeral names give more power to the 
CPs/CDNs over the content they publish. Our evaluation 
shows that even with a limited number of nodes implement¬ 
ing the LIRA architecture, ISPs achieve a clear performance 
gain, while at the same time CPs/CDNs have full control of 
their content. 
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